Secure database featuring separate operating system user

ABSTRACT

Embodiments manage access to cryptography keys for database data, within a secure key store of a local key server owned by a new (security) operating system (OS) user separate from an original default OS user. Existing principles governing distinct OS user access privileges engrained within the OS itself, are leveraged to preclude the default OS user from accessing files of the new security OS user. Embodiments thus segregate the right to read secure cryptography keys of a secure key store, from the right to administer database installation on the OS level. While the original default OS user retains access to the encrypted data, the new security OS user now owns the cryptography key necessary to decrypt that database data. Thus, the default OS user is denied enough information to unlock the database data, enhancing its security. Embodiments are particularly useful for promoting data security in cloud setups and multi-tenant databases.

BACKGROUND

Unless otherwise indicated herein, the approaches described in thissection are not prior art to the claims in this application and are notadmitted to be prior art by inclusion in this section.

Databases offer a useful way of storing large volumes of data that maybe organized into complex data structures. Prior to the advent of theinternet, databases were typically located on-premises at an enterprise,and dedicated exclusively to the storage of information of thatparticular enterprise. Such physical control and exclusivity of purposehelped to ensure the security of data stored within the database.

Increasingly, however, databases are located remotely from theenterprise on the cloud, and accessed over communications networks.Moreover, in the interest of cost-efficiency, a third party mayadminister a database whose hardware/software/infrastructure resourcesare shared between a plurality of enterprises (e.g., as differenttenants). While reducing cost, such database-sharing arrangementsimplemented by a remote host, can create risks lessening the degree ofsecurity afforded to data stored within the database.

SUMMARY

Embodiments manage cryptography keys for accessing database data, withina local key server owned by a new (security) operating system (OS) userseparate from an original (default) OS user. Existing principlesgoverning distinct OS user access privileges engrained within the OSitself, are leveraged to preclude the default OS user from unauthorizedaccess to cryptography key files of the new security OS user.Embodiments thus segregate the right to read secure cryptography keysaffording access to database data in decrypted form, from the right toadminister database installation on the OS level. While the originaldefault OS user retains access to the database data in encrypted form,the new security OS user now owns the cryptography key necessary todecrypt that database data. In this manner, the default OS user isdenied enough information to unlock the database data, thereby limitingaccess and enhancing security. Embodiments are particularly useful forpromoting data security in multi-tenant databases.

An embodiment of a computer-implemented method comprises receiving abinary identifying authorized installation or update of a databasesystem storing encrypted database data, and generating a first operatingsystem (OS) user for the database system, the first OS user comprising akey service manager. A second OS user is generated separate from thefirst OS user and comprising a key server protecting a first key todecrypt the encrypted database data. The key server performs anauthentication of a request for the first key from the key servicemanager, and the key server grants the key service manager access to thefirst key based upon the authentication.

A non-transitory computer readable storage medium embodies a computerprogram for performing a method comprising receiving a binaryidentifying authorized installation or update of a database systemstoring encrypted database data, and generating a first operating system(OS) user for the database system, the first OS user comprising a keyservice manager. A second OS user is generated separate from the firstOS user and comprising a local key server protecting a first key todecrypt the encrypted database data. The local key server performs anauthentication of a request for the first key from the key servicemanager, and the local key server granting the key service manageraccess to the first key based upon the authentication.

An embodiment of a computer system comprises one or more processors anda software program executable on said computer system. The softwareprogram is configured to cause an in-memory database engine to receive abinary identifying authorized installation or update of a databasesystem storing encrypted database data, and generate a first operatingsystem (OS) user for the database system, the first OS user comprising akey service manager. The software program is further configured togenerate a second OS user separate from the first OS user and comprisinga key server protecting a first key to decrypt the encrypted databasedata. The software program is further configured to perform anauthentication of a request for the first key from the key servicemanager, and to grant the key service manager access to the first keybased upon the authentication.

In some embodiments the authentication comprises verifying the binary aspart of the request.

According to certain embodiments verifying the binary comprises creatinga checksum and comparing the checksum to an installation snapshot.

In particular embodiments the authentication comprises checking alibrary referenced by the request.

In some embodiments the authentication comprises comparing the binarywith data stored in the database.

According to various embodiments the authentication comprises checkingif debugging is disabled.

In particular embodiments the first key is stored locally with the keyserver.

According to some embodiments the first key is stored remote from thekey server.

In certain embodiments the first key is encrypted and access to thefirst key is granted utilizing a second key.

According to various embodiments the database comprises an in-memorydatabase, and the authentication is performed by an in-memory databaseengine of the in-memory database.

The following detailed description and accompanying drawings provide abetter understanding of the nature and advantages of embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a simplified view of a system according to an embodiment.

FIG. 2 shows a simplified view of an example of a database serverconfigured according to an embodiment.

FIG. 3 shows another embodiment of a system.

FIGS. 4A-B are flow charts for an example embodiment of a process forimplementing a local key server running as a separate OS user in adatabase system.

FIG. 5 illustrates an example computer system.

DETAILED DESCRIPTION

Described herein are methods and apparatuses that implement databasesecurity. In the following description, for purposes of explanation,numerous examples and specific details are set forth in order to providea thorough understanding of embodiments according to the presentinvention. It will be evident, however, to one skilled in the art thatembodiments as defined by the claims may include some or all of thefeatures in these examples alone or in combination with other featuresdescribed below, and may further include modifications and equivalentsof the features and concepts described herein.

Embodiments relate generally to encryption techniques in a databasesystem. Particular embodiments describe a database system comprising alocal key server running as a separate OS user for performing datadecryption operations.

An issue that may arise in the management of database resources, is thepotential unauthorized availability of cryptography key informationallowing decryption of secure database data. For example, a relativelylow-level technician at a remote host location may be tasked withproviding routine database support. However, that technician's statuslikely does not also entail access to the sensitive information storedwithin the database (e.g., for multiple different possible tenants).

In order to perform database support, the technician is granted accessto the operating system (OS) of the database. This allows the technicianto routinely start up the OS automatically after a power failure, systemcrash, or instance crash, without having to type in additionalcredentials, secure additional approval, etc.

Such an individual technician who is logging on to the system would beafforded access rights of a default OS user. That default OS user mayencounter reduced security measures, easing potential access tocryptography keys used to decrypt database data.

Thus, a (potentially low-status) individual gaining OS-level access toadministrate installation of an instance of the OS for the databasesystem, may undesirably also be afforded reduced-security access tosensitive cryptography keys.

Accordingly, embodiments relate to managing access to cryptography keysfor database data, within a secure key store of a local key server. Anew (security) OS user is created separate from an original default OSuser. Existing principles governing distinct user access privileges thatare part of the OS itself, are leveraged in order to preclude thedefault OS user from accessing files of the new OS user. Embodimentsthus segregate the right to read secure cryptography keys of a securekey store, from the right to administer database installation on the OSlevel. While the original default OS user retains access to the databasedata in encrypted form, the new security OS user now owns thecryptography key necessary to decrypt that database data. In thismanner, the default OS user is denied enough information to unlock thedatabase data, enhancing its security. Embodiments are particularlyuseful for promoting data security in multi-tenant databases.

FIG. 1 shows a simplified view of a system according to an embodiment.Specifically, system 100 comprises database server 102 which is incommunication with database 104.

The database server includes a default OS user 106, which is configuredto run certain database processes. An example of such a database processis to receive a query 108 (e.g., in Structured Query Language—SQL) froman end-user 109, to process that query upon the database, and thenreturn a responsive query result 110.

It is noted that the data 112 of the database is stored in encryptedform. In order to return a responsive query result, the default OS usermust be able to apply a key 114 to decrypt the database data. Asmentioned above, however, granting access to the database data inunencrypted form is not desirable for all possible OS users (e.g.,low-level support technicians).

Accordingly, in order to prevent access (malicious or otherwise) to thesecurity key, a local key server 120 is introduced running as a separate(security) OS user 122. Any OS user attempting to access thecryptography keys must do so through the separate key server.

In particular, a database system process would communicate with a socket124, and open the socket to the key server. The local key server couldthen verify the authenticity of the default OS user process according toan established process identifier 126.

For example the database system process may include particular binaryfiles and/or reference certain libraries, etc. while seeking access theencrypted database data. The key server can refer to stored data 127 inorder to perform authentication 128 that the request for data accessfrom the default OS user process is in fact appropriate.

This authentication can rely upon properties of the process identifier,such as:

-   -   confirming that the binary received from the default OS user was        signed with private vendor keys and originates from an original        binary package for the installation and/or maintenance of the        database system;    -   checking for any suspicious libraries loaded by the process        seeking access; and/or    -   checking if system is properly hardened (e.g. system-wide        debugging is disabled in a Linux kernel until the reboot has        occurred).        Still other approaches verifying authenticity of the default OS        user process seeking security keys, are described later below in        connection with the example.

Once authentication has been successfully accomplished by the local keyserver, the decryption key is sent via the socket from the security OSuser to the default OS user. The default OS user is now free toreference 130 the key in order to decrypt data stored in the database,and to return corresponding data 132 responsive to the query.

Example

One particular example is now presented in connection with FIG. 2.Specifically, this example relates to the HANA in-memory databaseplatform available from SAP SE of Walldorf, Germany.

A primary function of HANA as a database server is to store and retrievedata as requested by various applications. In addition, HANA may performadvanced analytics (e.g., predictive analytics, spatial data processing,text analytics, text search, streaming analytics, graph data processing)and includes extract, transform, and load (ETL) capabilities and anapplication server.

FIG. 2 shows a simplified view of the HANA database server 200configured according to an embodiment, in communication with thedatabase 202. When an instance of an OS user for the database system isinstalled and/or updated, an OS user name is generated by the databaseinstaller.

During normal operation, database processes corresponding to a databaseinstance are run by a default OS user 204 having a default OS user name.Here, the default OS user name is: “sidadm”.

The default user runs a database process 206 that includes a columnstore 208 comprising an in-memory representation of the data. TheIntegrated Data Encryption Service (IDES) 210 is a component that allowsapplications to store selected data in encrypted form, by ensuring thatthe application has only access to its own keys. Secure Store component211 represents database tables containing data encrypted with a keymanaged by the IDES.

The HANA database server includes persistence layer 250. The persistencelayer provides persistence of the execution of a system, usually bywriting its state to files or to a database.

In computer science, “persistence” refers to the characteristic of statethat outlives the process that created it. This is achieved in practiceby storing the state as data in computer data storage. Programs transferdata to and from storage devices and provide mappings from the nativeprogramming-language data structures to the storage data structures.

Three different types of persistence are shown in FIG. 2. Data VolumePersistence 252 is the HANA component responsible for reading (writing)data volumes from (to) the file system.

Redo Log Persistence 254 is the HANA component responsible for reading(writing) redo-log entries from (to) the file system. The Backup Service256 is the HANA component responsible for reading (writing) backup datafrom (to) the file system or the back_int-interface.

The default OS user further includes a key service manager 260. The keyservice manager is a shared component that provides access to encryptionkeys that are stored and controlled from outside the default OS user.

In particular, this key service manager functions as the databasesystem-side adapter for accessing the local key server present on asecond OS user 262. This second (security) OS user has the username:“cryptadm”.

The cryptadm security OS user is present on the same host as the sidadmdefault OS user, thereby allowing cryptadm to check some OS settings andmake sure the system is properly hardened, as described above. Forexample cryptadm checks the binaries of sidadm for authenticationpurposes.

This checking could not be accomplished if sidadm and cryptadm wereoperating on a different host. Specifically, an external machine wouldneed some private key (such as a password) to authenticate against thekey server. Such a private key could not be protected against an OSadmin having the same privilege as the HANA OS itself. Accordingly, thecryptadm security OS user utilizes a separate process running on thesame host.

In order to effectively segregate security functions from the default OSuser, the security OS user owns the Secure Store in the File System(“SSFS”) 264. The SSFS comprises an encrypted file or other datacontainer containing the keys for unlocking the data stored in thedatabase system.

The SSFS can be encrypted using a master key 266. The master key for theSSFS may also be located in the file system.

The SSFS can be unlocked by the master key. Keys stored in the SSFS canbe used to unlock the data persisted in the database system.

In one embodiment, each key may correspond to a different purpose. Forexample, the SSFS can contain a key for the persistence encryption.

When the data is encrypted (e.g., persistence encryption is activated),the key for the encrypted data can be stored in the SSFS. The SSFS canbe locked using the master key to provide an additional layer ofsecurity.

There is also a key for the IDES. The IDES may include a different keystore that stores keys specific to the applications running on thedatabase system.

For its own persistence, the Local Key Server can use the SSFS, which issecured with a Master Key. An integration with third-party hardwaresolutions is also possible.

Independent of the specific persistence implementation, the persisteddata is also backed up. That is, the key server must somehow connect tothe backup/restore cycle for its persisted keys.

These backups are encrypted as well. The local key server key is securedindependently of that backup encryption, so that the dual control of keymanagement (cryptadm) versus data management (sidadm) is not broken.

In its security role, the second OS user has several possibilities toverify authenticity of a requesting process from the default OS userseeking cryptography key access. For example, the requesting process maybe a binary signed with a private key of the vendor (e.g., SAP SE).

A normal OS level user running as sidadm, could not fake an authorizeddatabase system binary now seeking access to the secure keys. Accordingto embodiments, only processes contacting the local key server 232 fromthe database system and verified to be secure, are allowed access to thekeys. According to particular embodiments, sidadm binaries do not accessthe keys directly, but a copy of the keys will be handed out if thecaller has been verified.

This does not necessarily include any OS level user. For example, asdescribed herein the keys can be stored securely as a different OS user.Only signed database system binaries can access the secure keys storedin the local key server's persistent storage.

In certain embodiments, the SAP host agent may be used to start(directly or indirectly) both the key server and the HANA processes. Insuch cases, the SAP host agent could hand over a secret to both (keyserver and HANA) processes. That secret can be used to verify that noother unauthorized process is attempting to steal the keys.

The key server opens a socket 270, and a HANA database system processconnects to the socket. The OS alerts the security OS user which binary(program) is seeking to make contact.

The security OS user can have the OS show the binary file of theprocess. Then, a checksum over this binary can be created, and thatchecksum verified against an installation or maintenance snapshot.

According to particular embodiments, SAP ships a signed manifest inevery release/update containing all hashes of all included files of aninstaller; this can be reused by the key server. Thus every HANAinstallation and/or update provides a set of hashes of all the databasesystem binaries signed with a private key. So, the local key server ofthe cryptadm security OS user will have the public key to open thesigned list of hashes. The local key server can hash against the binaryof any contacting process, to authenticate that the binary of theprocess is indeed present in a list of verified signed database systembinaries.

Access to the database decryption keys to the default OS user sidadm maybe afforded by encrypting those keys with a public key of the default OSuser before transferring the secure keys to the local key server. Then,the user data is encrypted with a private key of the separate (security)OS user. Thus, the key used to decrypt database data may itself beprovided to the default OS user through a separate encryption/decryptionprocess. Those keys can be cached by the default OS user, but are notpersisted in accessible form for the default OS user.

Embodiments are not limited to the particular example shown in FIG. 2,and alternative embodiments may be implemented. For example, the keyservice manager may manage a mapping between an explicit purpose and apurpose-identifier (ID).

In such embodiments the local key server only has to deal with thepurpose-ID(s). While these purpose-IDs could be mere numbers, thepurpose itself is more complex (URL-like, or json) in order to cover avariety of usecases.

Moreover, it is noted that backups of the local key server consumeprocessing, memory, and bandwidth resources. Thus certain embodimentsmay support advance key-generation (including backup), so that switchingto a new key can be achieved more quickly.

Further, the changes for the data volume, redolog, and backup encryptioncan be implemented once a working key service manager with the correctAPI is available. Until the local key server is available, anintermediate version of the key manager with its own persistence, may beimplemented.

While the particular embodiments described so far utilize local keystorage, this is not required. According to some embodiments, a remotekey server could be utilized.

FIG. 3 shows a simplified view of such an alternative system embodiment300. Here, the local key manager 302 requests keys from a remote keyserver 306 utilizing a key transfer protocol 308 that utilizes publickeys 305, 304 for encryption. This ensures that transported keys areonly accessible to processes that have corresponding private keys.Hence, in case the local key server did not request keys from remote keyserver, it can discard the response. In case the local key serverrequested keys from remote key server, the local key server can decryptwith private key corresponding to 304 and sign before forwarding messageto the requesting database process. The local key server cannot accesstransported keys, as the message is still encrypted with public key 305.The database process can check the signature with key 304 and decryptmessage with private key corresponding to key 305.

The particular embodiment of FIG. 3, shows the remote key server run ina different cloud installation. Alternatively however, the remote keyserver could be on the customer side.

FIGS. 4A-4B depict flow charts for an example embodiment of a processfor implementing a local key server running as a separate OS user in adatabase system. It is noted that the processes described below areexemplary in nature and are provided for illustrative purposes and notintended to limit the scope of the disclosure to any particular exampleembodiment. For instance, methods in accordance with some embodimentsdescribed in this disclosure may include or omit some or all of theoperations described below, or may include steps in a different orderthan described in this disclosure. The particular methods described arenot intended to be limited to any particular set of operations exclusiveof all other potentially intermediate operations. In addition, theoperations may be embodied in computer-executable code, which causes ageneral-purpose or special-purpose computer to perform certainfunctional operations. In other instances, these operations may beperformed by specific hardware components or hardwired circuitry, or byany combination of programmed computer components and custom hardwarecircuitry.

In one embodiment, the process 400 may be performed at a database systemcomprising a database server in communication with one or moredatabases. The database server may include at least one processor and amemory storing programmed computer code executable by the processor forimplementing an additional level of security for the database system.

In the illustrated embodiment, process 400 begins at operation 401 byreceiving a binary package comprising an installation or update of thedatabase system. In response to receiving the binary package, process400 can generate a default OS instance for the database system(operation 402). In one embodiment, the default OS instance may includea default OS user that is operable to manage access to user data storedby the database system in the one or more databases. Process 400continues by generating another OS instance for the database systemseparate from the default OS instance (operation 403). This second OSinstance may include a local key server (or service) running as aseparate OS user in the database system. The separate OS user may beoperable to manage access to one or more secure keys used for unlockingthe user data.

In one embodiment, the separate OS user is generated in response to theinstallation or update of the database system. The separate OS user isprovided with the secure key store and master key file. The local keyserver may include a secure key store secured by a master key stored ina master key file. The secure key store can be adapted for storing thesecure keys in its own persistence in which the secure keys are securelystored. The master key can unlock the secure key store to access thesecure keys, and the secure keys can unlock the user data stored in thedatabase system.

In at least certain embodiments, the database system may be configuredsuch that no single OS user in the database system has enoughinformation to unlock the user data by itself when the local key serveris running as the separate OS user. Such a database configuration canprohibit or exclude the default OS user access to the secure keysmanaged by the separate OS user and can prohibit or exclude the separateOS user access to the user data managed by the default OS user.

Process 400 continues by receiving a request from a process for accessto one or more secure keys in the secure key store of the local keyserver (operation 404) and verifying that the binary of the processrequesting access is a database system binary that originates from thedatabase system (operation 405). The process may then be granted accessto the secure keys in the secure key store when the process binary isverified (operation 406). In one embodiment, only processes thatoriginate from the database system are granted access by the local keyserver.

Process 400 continues at FIG. 4B, which depicts further details of theoperations for verifying that the binary of the process requestingaccess is a database system binary that originates from the databasesystem. Process 400 continues by generating a hash of the process'binary (operation 407) and comparing it against a set of hashes of thedatabase system binaries (operation 408). In one embodiment, uponinstallation or update of the database system, the database systembinaries are unpacked from the binary package and hashed to generate theset of hashes of the database system binaries, which can then becompared with the hash of the binary of the process requesting access tothe secure keys in the secure key store of the local key server.

Process 400 continues by verifying the process binary when the hash ofthe process binary matches at least one hash in the set of hashes of thedatabase system binaries (operation 409). A hash function may refer toany function that can be used to map data of arbitrary size to data offixed size. The values returned by a hash function are called hashvalues, hash codes, hash sums, or simply hashes. One use is a datastructure called a hash table, widely used in computer software forrapid data lookup. Hash functions can accelerate table or databaselookup by detecting duplicated records in large files. A cryptographichash function allows one to easily verify that some input data maps to agiven hash value, but if the input data is unknown, it is deliberatelydifficult to reconstruct it (or equivalent alternatives) by knowing thestored hash value.

It should be noted that although embodiments are presented in terms ofhash functions, other fingerprinting and/or security techniques may alsobe used such as checksums, document fingerprints, randomized functions,error correcting codes (ECCs), forward error correction (FEC) codes,ciphers, etc. The presented embodiments are not intended to be limitedto any particular fingerprinting technique or techniques.

In at least certain embodiments, an additional privilege above OS accessprivilege is required to access the secure key store of the local keyserver. Separating the OS users prohibits access by one OS user ofanother OS user's files. Because of this, OS users in a database systemconfigured according to the embodiments described herein are not able toaccess the secure key store of the local key server owned the separateOS user.

Once the process binary is verified as a binary originating from thedatabase system, the process can be granted access to the secure keys.Process 400 continues by the local key server encrypting secure keyswith the public key of the default OS user and signing with the privatekey of the separate OS user, before the local key server transmits datato the requesting process (operation 410). In one embodiment, the securekeys stored in the secure key store can be accessed using a keyreference of a requesting database system process such as from the keyservice manager discussed above.

At least certain embodiments may be configured for implementation usingin-memory analytics. In-memory analytics is an approach to querying datawhen it resides in a computer's random access memory (RAM) as opposed toquerying data that is stored on separate physical disks. This can resultin vastly shortened query times, allowing business intelligence andanalytics applications to support faster business decisions. In additionto providing fast query response times, in-memory analytics can reduceor eliminate the need for data indexing and storing pre-aggregated data.This can reduce IT costs and allow faster implementation of businessintelligence and analytics applications.

In one embodiment, a system described in this disclosure can beimplemented on a SAP HANA platform, which is an in-memory,column-oriented, relational database management system developed andmarketed by SAP SE based in Walldorf, Germany. The HANA platform allowsdata analysts to query large volumes of data in real time, and itsin-memory database infrastructure can free analysts from having tocontinuously load or write-back data to physical disks. Certainembodiments may leverage the processing power of an in-memory databaseengine in order to function in one of the roles and/or perform one ormore of the tasks that have been described above.

An example computer system 500 is illustrated in FIG. 5. Computer system510 includes a bus 505 or other communication mechanism forcommunicating information, and a processor 501 coupled with bus 505 forprocessing information. Computer system 510 also includes a memory 502coupled to bus 505 for storing information and instructions to beexecuted by processor 501, including information and instructions forperforming the techniques described above, for example. This memory mayalso be used for storing variables or other intermediate informationduring execution of instructions to be executed by processor 501.Possible implementations of this memory may be, but are not limited to,random access memory (RAM), read only memory (ROM), or both. A storagedevice 503 is also provided for storing information and instructions.Common forms of storage devices include, for example, a hard drive, amagnetic disk, an optical disk, a CD-ROM, a DVD, a flash memory, a USBmemory card, or any other medium from which a computer can read. Storagedevice 503 may include source code, binary code, or software files forperforming the techniques above, for example. Storage device and memoryare both examples of computer readable mediums.

Computer system 510 may be coupled via bus 505 to a display 512, such asa cathode ray tube (CRT) or liquid crystal display (LCD), for displayinginformation to a computer user. An input device 511 such as a keyboardand/or mouse is coupled to bus 505 for communicating information andcommand selections from the user to processor 501. The combination ofthese components allows the user to communicate with the system. In somesystems, bus 505 may be divided into multiple specialized buses.

Computer system 510 also includes a network interface 504 coupled withbus 505. Network interface 504 may provide two-way data communicationbetween computer system 510 and the local network 520. The networkinterface 504 may be a digital subscriber line (DSL) or a modem toprovide data communication connection over a telephone line, forexample. Another example of the network interface is a local areanetwork (LAN) card to provide a data communication connection to acompatible LAN. Wireless links are another example. In any suchimplementation, network interface 504 sends and receives electrical,electromagnetic, or optical signals that carry digital data streamsrepresenting various types of information.

Computer system 510 can send and receive information, including messagesor other interface actions, through the network interface 504 across alocal network 520, an Intranet, or the Internet 530. For a localnetwork, computer system 510 may communicate with a plurality of othercomputer machines, such as server 515. Accordingly, computer system 510and server computer systems represented by server 515 may form a cloudcomputing network, which may be programmed with processes describedherein. In the Internet example, software components or services mayreside on multiple different computer systems 510 or servers 531-535across the network. The processes described above may be implemented onone or more servers, for example. A server 531 may transmit actions ormessages from one component, through Internet 530, local network 520,and network interface 504 to a component on computer system 510. Thesoftware components and processes described above may be implemented onany computer system and send and/or receive information across anetwork, for example.

The above description illustrates various embodiments of the presentinvention along with examples of how aspects of the present inventionmay be implemented. The above examples and embodiments should not bedeemed to be the only embodiments, and are presented to illustrate theflexibility and advantages of the present invention as defined by thefollowing claims. Based on the above disclosure and the followingclaims, other arrangements, embodiments, implementations and equivalentswill be evident to those skilled in the art and may be employed withoutdeparting from the spirit and scope of the invention as defined by theclaims.

What is claimed is:
 1. A computer-implemented method comprising:receiving a binary identifying authorized installation or update of adatabase system storing encrypted database data; generating a firstoperating system (OS) user for the database system, the first OS usercomprising a key service manager; generating a second OS user separatefrom the first OS user and comprising a key server protecting a firstkey to decrypt the encrypted database data; a default process of thefirst OS user opening a socket to the key server; the key serverperforming an authentication of a request for the first key from the keyservice manager, the request including the binary communicated via thesocket, wherein the database system comprises an in-memory database, andthe authentication is performed by an in-memory database engine of thein-memory database, and wherein the authentication comprises, creating achecksum over the binary, and verifying the checksum against aninstallation or maintenance snapshot; and the key server granting thekey service manager access to the first key via the socket based uponthe authentication, wherein, the authentication comprises checking alibrary referenced by the request, and the first key is encrypted, andaccess to the first key is granted utilizing a second key.
 2. A methodas in claim 1 wherein verifying the binary comprises: creating achecksum; and comparing the checksum to an installation snapshot.
 3. Amethod as in claim 1 wherein the authentication comprises comparing thebinary with data stored in the database.
 4. A method as in claim 1wherein the authentication comprises checking if de-bugging is disabled.5. A method as in claim 1 wherein the first key is stored locally withthe key server.
 6. A method as in claim 1 wherein the first key isstored remote from the key server.
 7. A non-transitory computer readablestorage medium embodying a computer program for performing a method,said method comprising: receiving a binary identifying authorizedinstallation or update of an in-memory database system storing encrypteddatabase data; generating a first operating system (OS) user for thedatabase system, the first OS user comprising a key service manager;generating a second OS user separate from the first OS user andcomprising a local key server protecting a first key to decrypt theencrypted database data; a default process of the first OS user openinga socket to the key server; the local key server performing anauthentication of a request for the first key from the key servicemanager, the request including the binary communicated via the socket,wherein the authentication is performed by an in-memory database engineof the in-memory database, and wherein the authentication comprises,creating a checksum over the binary, and verifying the checksum againstan installation or maintenance snapshot; and the local key servergranting the key service manager access to the first key via the socketbased upon the authentication, wherein, the authentication compriseschecking a library referenced by the request, and the first key isencrypted, and access to the first key is granted utilizing a secondkey.
 8. A computer system comprising: one or more processors; a softwareprogram, executable on said computer system, the software programconfigured to cause an in-memory database engine to: receive a binaryidentifying authorized installation or update of an in-memory databasesystem storing encrypted database data; generate a first operatingsystem (OS) user for the database system, the first OS user comprising akey service manager; generate a second OS user separate from the firstOS user and comprising a key server protecting a first key to decryptthe encrypted database data; open a socket to the key server; perform anauthentication of a request for the first key from the key servicemanager, the request including the binary communicated via the socket,wherein the authentication comprises, creating a checksum over thebinary, and verifying the checksum against an installation ormaintenance snapshot; and grant the key service manager access to thefirst key via the socket based upon the authentication, wherein, theauthentication comprises checking a library referenced by the request,and the first key is encrypted, and access to the first key is grantedutilizing a second key.
 9. A computer system as in claim 8 wherein thefirst key is stored locally with the key server.
 10. A computer systemas in claim 8 wherein the first key is stored remote from the keyserver.